11/9-12/3: Final Bug Push

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

Steam Release (6 hours)

I spent much of my time this week helping out with the steam release. Although the steam release likely won’t be available until the middle of January, there is still a lot of work to do. The important elements of the steam release are:

• Trailer Preparation: A good steam release needs a trailer, and to do that, they need cinematic shots of their units. To ensure that our marketing team could get those trailer shots, I created a cinematic camera in-game. Rather than marketers needing to clone the repository and mess with the Unity editor, they could enter a command such as “cinematic pan” to pan around a unit. This feature took a bit of time to implement, but it ensured our trailer makers could get good shots.

• Release Coordination: I spent a couple hours this week in meetings and conversations with our marketing team (Antonio Perez and Athena Nguyen) to hash out the details regarding the steam release. These basically resolved the details of who would do which parts, the structure of the trailer, and the overall timeline of the effort (to get a steam page ready in time for the showcase, we would have to get it right first try).

• Copy Writing: I spent time writing up the description of the game (which took a while to find the right words) and filling out various steam forms (they get very granular about the maturity ratings).

• Graphical Assets Generation: Steam pages require graphical assets to be displayed. Halina Nguyen of the art team made cover art and sent me a Photoshop file of this cover art to use on the page. Unfortunately, this did not fit the required dimensions, so I had to go into photoshop and make different assets for each dimension. This required me to learn Photoshop.

Bug Fixes (8 hours)

I fixed a lot of bugs, including:

• Fixed a bug in Tutorial 1 where units were not selectable.

• Fixed null reference exceptions for the AI on maps that don’t have Key Locations

• Prevented the player from being able to spawn a unit with no type

• Fixed a bug that prevented camera pan at the lowest zoom level

• Improved unit flow by ensuring that clicking off a unit cancels their movement

• Fixed bugs where the wizard could not attack

• Prevented the player from moving to a different tile than they’re supposed to in Tutorial 3

• Fixed a bug where the “guest” could not see their champion in the multiplayer lobby

• Fixed a bug where the other player’s walking animations would not play

• Fixed a bug where players received more gold than they should have

• Fixed a bug where commander special cancelling caused unintended behavior.

• Fixed a bug where the Arch Mage and Old King special abilities would not work

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 80 pull requests in the past two weeks, which is nowhere close to the highest number. Unfortunately, many of those pull requests had substantial merge conflicts, and getting ensuring the scenes did not break took up a lot of my time. In the end, I was able to do it.

11/5-11/19: Options Menu & Stability

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

Options Menu (3 hours)

While feature work on the game was winding down, I still had at least one medium sized feature to work on - the options menu. The options menu was put off until the very last minute, and Howard worked on the visual skeleton for the pause menu, but now I needed to fill it with features.

The features I implemented include:

• Audio Settings - Audio settings are a standard for all games, especially WolverineSoft Studio games, and they needed to be implemented in this game. I worked in both Unity and WWise to make the audio sliders. I implement the audio settings through WWise buses, which can modify the properties of incoming audio (such as the volume).

• Camera Panning Settings - We have received feedback that certain players don’t enjoy the Camera Panning, specifically the mouse camera panning. I made settings to turn mouse camera panning on and off (WASD camera panning is always enabled to ensure the map can be traversed) and to change the speed of the camera panning.

• Exhaust Settings - There are some players that want to manually end their own turns rather than having it be “exhausted” when the player can’t do anything else. Thus, I made settings to allow players to turn it off.

Unit Changes (1 hours)

In addition to the settings menu, I also made the following (relatively quick) changes to the units:

• Units now have counters (for instance, if a Sorcerer attacks a War Balloon, they do 40 extra damage)

• Units now change their damage based on their health (for instance, if a unit has 75% health, they do 75% damage).

Bugs & Stability (8 hours)

I worked on a lot of bugs this week, including:

• Fixed the integration of the IsCapturable component (refactoring the logic of capturing from a City to a separate component)

• Fixed the War Balloon’s animations, which got reverted due to a merge conflict

• Fixed a bug where players spawn without a Faction assigned

• Fixed a bug where cities would not display the proper mesh (which I had to fix several times)

• Fixed a bug where the Lobby screen would not update correctly to show the other player’s images

• Fixed a bug where cities would not be selectable

• Fixed a bug where Key Location captures would not send messages correctly

• Fixed a bug where the tutorial missions did not set the player’s turn correctly.

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 104 pull requests this sprint (audio not included, as Daniel does most of that), which is double the previous two week period. Much of my time was spent on solving merge conflicts, of which there were only a lot (I counted 15); These merge conflicts were complicated, as they would involve complex features that change and add elements to prefabs and scenes. Solving these conflicts involved advanced techniques, such as using transfer prefabs. Overall, the negative impact of merge conflicts on the team were mitigated.

Meetings and Office Hours (4 hours)

A lot of my time this week has been spent in meetings. There are a few types of meetings:

• The Weekly “All Hands” meeting: 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. This time is mostly used by artists and audio people to ask me questions and talk to me about potential plans

10/22-11/4: Various Changes and Youmacon

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

Codex Refactor (8 hours)

The bulk of my feature implementation work was spent on the Codex. The Codex is the game’s encyclopedia (similar to Wargroove). It enables players to have one source of reference for the game’s mechanics, lore, and characters. While we will also have a tutorial, complex strategy games benefit from a well designed encyclopedia.

New features to the Codex includes:

• Revamped Categorization: While the Codex had categorization in some capacity, the categories system was not scalable (i.e. they were hardcoded in the game rather than implemented in a flexible way). I had to refactor the categorization, which was a very heavy refactor. There’s now a difference between a Codex entry’s category (e.g. lore, characters, mechanics, units) and its type (e.g. regular, unit, terrain). An entry’s category determines which subheader it goes to, while an entry’s type determines what pages get shown. The two were treated as the same in the old codebase, but now are different in the new codebase.

• Damage Matrix: Players need to know how much damage a Unit will do to another unit. Thus, all the unit pages contain a Damage Matrix, a list of all the units and what damages they give and receive. This involved added a method to the battle system to calculate damage on UnitTypes (the scriptable objects) rather than the Unit prefabs themselves.

• Terrain Matrix: Players also need to know what units can move onto which tiles, and what the cost is for each tile. Thus, the Terrain Matrix gives players this information.

• Codex Searching: In addition to navigating the Codex through the menus, it is nice to give players the option to navigate through a search bar. This feature is rare in codexes, but when it is implemented, it gives players a better user experience. I made a very simple search engine that searches through all the entries based on their title and internal text.

Repository Management (5 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 52 pull requests this sprint (audio not included, as Daniel 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 only a lot (I counted 9-10); These merge conflicts were complicated, as they would involve complex features that change and add elements to prefabs and scenes. Solving these conflicts involved advanced techniques, such as using transfer prefabs. Overall, the negative impact of merge conflicts on the team were mitigated.

In addition to merging and solving conflicts, I spent a lot of time providing my programmers with good feedback on their code. Code reviews and feedback structures are important in general because they ensure the quality of a codebase. I make sure that their code most likely work and ensure that I give actionable feedback that makes a difference without being pedantic.

Meetings & Office Hours (5 hours)

A lot of my time this week has been spent in meetings. There are a few types of meetings:

• The Weekly “All Hands” meeting: 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. This time is mostly used by artists and audio people to ask me questions and talk to me about potential plans.

• Leadership Meetings: This is where leadership meets to discuss the state of the project. While these generally overlap the “All Hands” meeting, they did not this week. This is because, although Programming and Design are generally on track, there is a lot of art integration work that needs to get done that hasn’t been done. As a result, the leads meetings took longer than expected.

9/24-10/8: AI Improvements

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

AI Strategies (9 hours)

Most of my time these two weeks were spent on the AI. Our game allows players to play against a computer controlled opponent. While complex, the development of this feature will allow us to better test our mechanics (i.e. you don’t always need a multiplayer match to test things like UI changes), and ensure recruiters can play our game regardless of the state of Photon.

The AI essentially works like this:

• Every iteration of every turn, the enemy AI calculates all of the possible moves it can do and adds them to a list. For instance, the AI lists every city that it could capture, or every unit that could defend the commander.

• The AI evaluates each move one by one, assigning it a score. Higher scoring moves are better.

• The AI executes the highest scoring move, and repeats the process until it can longer move. Once it is done moving, it ends the turn.

A snippet of the data structure outputted for each strategy

The AI already had some work done over the summer. However, the AI needed a substantial amount of improvement in order to make it interesting to play against. I worked with the AI designer to make the changes necessary. The changes I spent the sprint working on are:

• Prioritizing Free Cities: The AI should go after “free” cities before contested cities. “Free cities” are cities that are either neutral or not well defended. The AI should also prioritize helping capture cities where the capturing unit is at a disadvantage. This involved creating a metric called “Battle Strength” to determine exactly who has the numerical advantage in a fight for the city.

• Prioritizing Helping Other Units: The AI should look for opportunities to get easy kills (i.e. to kill a unit without taking much damage, or to have a friendly unit nearby). This involved a similar calculation to the battle strength.

• Prioritize Attacking the Commander: Commanders in Project Multiply are a core component of the game - killing them wins the player the game by default. As a result, the enemy needed to heavily prioritize attacking the commander to ensure it would be damaged.

• Assist Commander: The AI needs to protect its own commander. If the commander is in danger from other units, the AI needs to find the nearest unit and prioritize defending the commander. This involved creating a new strategy class called the FollowCommanderStrategy and moving near the commander. The hardest part about this strategy was figuring out what position the unit should move to; a unit needs to find the position that will block the opponent’s units from attacking the commander.

• Escape from Danger: If a unit is in danger of being killed, they should attempt to get out of the area immediately. The hardest part about this strategy is figuring out the best position to move to. Right now, the AI calculates the average position of the surrounding enemies and finds the opposite direction to that.

AI Debugger (5 hours)

While testing out my strategies, I found that it was hard to determine what exactly the AI was trying to do and why. I knew that if I had trouble, the other programmers and designers would have trouble as well.

My solution to this was the AI Debugging tool. This tool could show all the strategies the AI calculates and display its score, along with any notes. This tool enables me to actually see how the AI is making their calculations and compare its results to my expectations. This tool makes future design decisions and iterations much easier.

In addition to the display, I added several connivence features, including the ability to breakpoint on calculations and the ability to see previous turns

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 75 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 only a few; however, some of these merge conflicts were complicated, as they would involve the entire Unity prefab and require several merges. Solving these conflicts involved advanced techniques, such as using transfer prefabs. Overall, the negative impact of merge conflicts on the team were mitigated.

In addition to merge conflict resolution, I spent some time hotfixing and repairing the build, including:

• A fix for automated files being created by our third party packages (I just had to change the build file string)

• Integrated Parrel Sync, a package that many of my programmers wanted to make development easier

• Fixing the spawning UI when a failed merge conflict resolution left the player unable to spawn air units.

4/2-4/18: Lots of Bug Fixes

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

Bug Fixes (10 hours)

I fixed a lot of bugs this week, including:

• Fixed a bug where the shop would not deduct currency

• Fixed a bug where keys would not save between scenes

• Fixed a bug where clicking a purchased ability would not equip it

• Fixed a bug where previewing the energy burst would cause every subsequent preview to fail

• Fixed a bug where the shop preview was not visible in the hub

• Fixed a bug where the camera track system would play after every death

• Fixed a bug where spawned enemies in the Viking boss fight would not despawn when the fight ends

• Fixed a bug where melee upgrades would not save between scenes

• Fixed a bug where the player’s movement gets reset when an encounter starts

• Fixed a bug where pausing the time while performing time slow would lock the player

• Fixed a bug where level progress would not reset when the game loads

• Fixed a bug where the volume slider text would overflow its container

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:

1. 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.

2. 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. This time is mostly used by artists and audio people to ask me questions and talk to me about potential plans.

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 240 pull requests during this period (Audio not included), which might be a new record for two weeks of development (it does include spring break). Most of the pull requests were not big, as I advised my members to push and make pull requests as quickly as possible to prevent merge conflicts. However, there were a lot of changes made over these two weeks as the team worked tirelessly to get everything in.

3/12-4/2: Shop and Art Integration

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

Art & Animation Integration (8 hours)

Much of my three weeks were spent on art and animation integration. Art made a lot of progress over the past few weeks, but so many things were not integrated, so programming volunteered to help. The art and animation integration I worked on includes:

• Integrate the Player Dash Animation. The player dash animation was tricky because they didn’t use the preexisting skeletons (because the dash animation involves the player turning into a squid), so I had to create a new sprite on the player and ensure that it properly turns itself on and off.

• Integrated the animations of the lunging and thrusting enemies. This wasn’t too bad, as the animation graph was fairly simple to create.

• Integrated the animations of the first boss (the Starfish). This was significantly more challenging than integrating the animations of a single enemy because the boss’s logic is more complex. While an enemy may only have a single attack, the first boss had multiple attacks, each with their own windup and cooldown animations. It took a lot of time to get the graph to be correct.

• Integrated the animations of the final boss. This was complicated but in a different way. The final boss is the demon, who summons the previous two bosses. As a result, the final boss needs to play the animations of the first two bosses, which would properly enable and disable the sprites.

• Integrated the art for several level design elements, including the arrow traps, bridges, and crushing traps. These were easy to integrate, but very hard to keep polished (and there are still issues).

The lunging enemy animator

The FInal Boss Animator

Main Menu (8 hours)

I spent much of the first week of this devlog (in addition to art integration) working on the main menu. There were several tasks for the main menu, and they were:

• Ensuring that the buttons are displayed correctly depending on whether the player has save data. If the player has previously played the game, the main menu should give the option of “New Game” or “Continue”. If this is the player’s first time playing, then the player should have just see the “Play” button. This wasn’t too bad of a feature to create.

• Creating the Audio settings menu. This involved going into WWise to setup volume buses, and then integrate them with the new sliders. Creating a bus in WWise is not difficult by itself, but the bigger challenge was hooking the volume buses and parameters up to actual sound effects. I had to a lot of digging to ensure everything was hooked up.

• Creating the controls settings menu. This required me to create the controller remapping (and key rebinding) feature. This was fairly challenging, particularly because the designers wanted the movement controls (W, A, S, and D) to be rebindable. It took me quite a bit of time to get a single button rebindable (Unity’s API is not well documented), and getting multiple keys for a single action to be rebindable was even harder. I also needed a system to display icons for buttons that aren’t keys, including the mouse buttons and controller buttons. I was able to get something working eventually.

• Integrating the credits into the main menu. This wasn’t too bad, because the WolverineSoft General Library has a script that does credits for us. Figuring out how it worked took a bit of time though.

The volume busses in WWise

Shop Preview (4 hours)

The final feature of this sprint was the Shop Preview. The UI designers wanted items in the shop to be previewable, so players can get an accurate representation of the items. This required me to make a new prefab in the levels with a player animator (but not a player controller, because that is a singleton), and have that play animations. There were several issues stemming from the fact that the shop always has a timescale of 0, so I had to do several hacks to get the animations to play the way I wanted them to. The most complex was the reflect ability, which required me to shoot a bullet, manually making it move, play the sword swipe, and make it reverse direction when the bullet hits the sword.

Repository Management (7 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 165 pull requests during these three weeks (audio not included, as Gibby does most of that). An additional 15 were merged by in our future programming lead, Allie. This is probably the most amount of pull requests for any three-week period in the history of WolverineSoft, and includes the largest number of pull requests in any single semester project (only 80 away from beating the record for any WolverineSoft project).

This large amount of pull requests was challenging on its own, but the amount of merge conflicts I needed to solve were even harder. There were 29 merge conflicts to solve. Some were fairly easy (only involved a single value being changed), but others were more complicated, as they involved changes to tilemaps. I tried my best to merge everything losslessly, but not all of it was able to get in, and some people had to redo their work.

2/19-3/12: Bug Fixing and Art Integration

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

Player Animation Integration (4 hours)

I was tasked with integrating the player’s walk, idle, and slash animations onto the player character. The task ended up much harder than I expected because of how animations work. The player has four different directions that they can be facing, which means four different sprites. Each sprite has its own skeleton for skeletal animation. Using a blend tree causes multiple skeletons to be active at once, leading to a lot of visual errors.

To fix it, I had to ensure the animator didn’t blend the animations, I created a custom script to call the animations. This script, which exerted manual control over them, ensured that animations don’t overlap, but took a lot of time to make work.

Bug Fixes (7 hours)

In addition to art integration, much of my stability week was focused on bug fixes. The bugs I fixed this week are:

• Fixed a bug where Level 1 Checkpoints did not work. This took 2 hours of debugging, but there were multiple compounding issues. Teleporting the player does not work because the Physics2D function used does not work when a collider is between the current position and the intended position. The default checkpoint (i.e. the checkpoint at the start) was overriding the saved checkpoint, so both issues had to be fixed.

• Fixed a bug where the player could dash through a single tile of wall. This involved making the player use a raycast to check if the dash is valid before starting it.

• Fixed a bug where pressing “New Game” sends players to the saved checkpoint instead of the start of the game. This was fixed by having the “New Game” option explicitly delete the save file (which will be refactored with more options in Sprint 3).

• Fixed a bug where stopping the Time Slow ability did not stop the stamina drain. This involved calling a function to stop the stamina drain.

• Fixed a bug where the sword reflect upgrade works before buying it. This is because all the player upgrade start as purchased rather than not purchased.

• Fixed various null reference exceptions to improve performance

• Fixed a bug where the player’s movement will be restricted when moving along said wall. This involved changing the size of the player collider to better indicate wall placement.

• Fixed a bug where arrow trap projectiles pass through walls. This involved making the projectiles destroy themselves when colliding with a wall.

• Fixed a bug where players on keyboard need to use the joystick to move (if a controller is plugged in but not active). This required me to use Unity’s method of looking for the active device rather than my own.

• Fixed a bug where the player’s gun does not save between scenes. This functionality never existed, so I made it.

Repository Management (5 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 95 pull requests during these three weeks (audio not included, as Gibby does most of that), which might be a new record for two weeks of development (it does include spring break). Much of that time was spent fixing merge conflicts, which were more time consuming than normal due to the amount of changes to 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 (3 hours)

A lot of my time this week has been spent in meetings. There are two types of meetings:

1. 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.

2. 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. I only hosted one this sprint, as I had to cancel the one on February 23rd due to a blackout.

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:

1. 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.

2. 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

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:

1. 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.

2. 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.

11/27-12/11: Final Bug Fixes

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

Art Integration (2 hours)

Although we had gotten a lot of artwork integrated into the game, there was still one final piece that needed to get in: the enemy art. All throughout development, we had been using a placeholder ship that one of our artists made. It didn’t look too out of place at first, but as more art got in, the enemy ship stood out. The art lead, Nicholas, and I made a last-ditch effort to get a more cohesive version of the enemy art in. I spent a lot of time this week putting the new enemy art assets (i.e. the ship, room, icons, and backgrounds) into the game and fixing the surrounding issues that occurred. Since we had a new ship, adjustments needed to be made to the room positions and scale until everything fit, and the new ship needed to face in the correct direction. Below is the final result and the original concept art (created by Nicholas).

A screenshot of the ship as it appears in game

The original concept art by Nicholas Way, created in late september

Bug Fixes (6 hours)

As it was the final week of development, a lot of my time was spent on bug fixes. The bugs I fixed included:

• When rooms get removed, the art also gets removed and reverts back to the empty display

• The “HIT” display only appears when a weapon hits the enemy ship rather than the shield

• The “HIT” display shows the word “DETECTED” when a sonar projectile hits the shield

• Enemy crew member no longer display the player animations

• Attempting to start a new campaign no longer jumps encounters at random

• Player’s crew list no longer displays stretched out versions of the crew

• Enemy health bar is no longer out of the player’s view

• Player crew animations no longer stop when the crew is hit by a projectile

• Player crew can now be clicked in a wider range

Credits Integration (1 hour)

This semester, our team put in a lot of hard work into the game. It is important that they get credited correctly. I spent time this week putting in every member’s name into the credits and reorganizing the credits into Cycle 1, Cycle 2, and Voice Work sections. In addition, I added new concept art to the credits, to ensure more artists have their work shown. You can view the credits below (note that I made some adjustments after this video was taken to ensure everyone got into the credits):

Video Block

Double-click here to add a video by URL or embed code. Learn more

11/13-11/27: Polishing The Game

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

Art Integration (3 hours)

A lot of my time this week was helping out with the art integration. Our artists have been hard at work creating assets for the game, but due to production delays, most of it was not in the game. This became a problem for the state of the game and the motivation of the team. I worked directly with our art lead to integrate our existing assets, which includes:

• Icons for different rooms and systems

• Room art for the weapon, sonar, shield, and medbay rooms

• UI Recoloring and Icon changes

• Character Portraits for various narrative characters

Below, you can see before and after pictures:

Bug Fixes (3 hours)

In addition to art integration, a substantial amount of my time was spent fixing bugs in our game. Our big feature broke a lot of elements of the game, so it was our duty as a programming department to fix them. I fixed many bugs, including:

• Fixed a bug where players can’t replace systems or crew correctly

• Fixed a bug where pause menu buttons were not functional

• Fixed a bug where alive crew members will disappear when damaged

• Fixed a bug where the player can’t have more than 2 weapons

• Fixed a bug where pathfinding was unsuccessful

• Fixed a bug where the buffbay would not appear in the ship during combat

• Fixed a bug where empty rooms would be marked as destroyed internally

Tutorial Improvements (2 hours)

I also focused on improving the tutorial based on feedback from design. The big improvements are:

• The player is physically restricted from purchasing systems out of order, or from purchasing crew before systems

• The player is forced to place systems in specific rooms, rather than being able to choose

• The player can’t have a shield manned at the start of combat

• The player is now forced to have a medbay

• The player is now forced to have two crew members

• The crew’s highlight is now much more polished.

Repository Management (2 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 44 pull requests these past two weeks, which was (thankfully) not as high as the previous sprint. Because we were focused on bug fixing, our merge conflicts were substantially less impactful than in previous sprints.

10/30-11/13: The Final Feature Push

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

Improved Tutorial (3 hours)

A lot of the feedback from last sprint’s stable build was focused on the way the tutorial works. The tutorial works properly, but there is a lot of text, not a lot of visual indicators, and can be circumvented (or broken) if the player performs actions in a different order than the tutorial wanted. I worked with our UI designers to improve the tutorial. The major improvements are:

• We now only have a single tutorial box in the game. The player only needs to focus on a single area of the screen, which has been specifically designed to not block anything else, for their tutorial messaging. Unlike the previous version, the tutorial box does not disappear until the player completes the action, ensuring they don’t feel soft-locked.

• The tutorial has far fewer lines of text. Much of the narrative “bloat” has been stripped out of the tutorial, making it much more readable for players.

• We now have far more visual indicators for how the player needs to perform actions. These include overlays, which block out specific parts of the screen to highlight objects, and arrows to show the player how to drag items.

Ship Building Improvements (5 hours)

I worked with our UI/UX designers to make substantial improvements to the ship-building flow. These were some final features in how the player interacts with the phase, and they include:

• The addition of “filters” for ship systems. This is just like a filter in a store website, in that it enables you to focus on a specific category of items (in this case, weapons, shields, medbays, and other).

• The ability to select items in the shop rather than just drag them. By selecting an item, you can view it’s information even when other items are hovered.

• The ability to buy back health from the game if your ship is damaged.

• Various bug fixes for the shop, including a fix that allows you to buy ship upgrades.

Designer Support (4 hours)

A lot of my time this sprint was spent on supporting designers in their role as they integrate assets into the game. Almost every designer went into Unity for the first time this sprint, and they were lost. I told Kelly, the design lead, to tell her designers to contact me for support. The designers were working on everything from balancing to narrative integration to UI/UX design, and there was no one-size-fits-all approach to helping them. I spent a lot of time this week answering their questions individually on discord, and pointing them to the correct places.

In addition, I participated in two meetings with designers to assist them. I had a one-on-one meeting scheduled with a combat designer to show him around the engine and point him to where he would need to make changes. I also had a design session with Kelly and a few designers from the messaging squad, where I walked them through how our UI was structured and where to make design changes. I was very happy with their work, as they are picking up in-engine work relatively quickly.

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 54 pull requests these past two weeks, which was (thankfully) not as high as the previous sprint. However, there were more substantial merge conflicts this time, due to the speed at which we were getting features in and the fact that designers were merging things into the game themselves. I was able to successfully navigate a lot of the conflicts (although we get strange errors about broken pointers).

A bigger thing this sprint was the amount of time I spent looking at other people’s branches to finish their implementation. Several of my programmers told me that they felt like they were mostly complete, but we’re getting stuck on the final step of their implementation. As a result, they asked me to look at their branches and try to find the bugs. I was able to do this successfully thanks to my knowledge of the codebase and good debugging tools.

Programming Meetings and Office Hours (2 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. These meetings have been shorter as we exit feature work and go into bug fixing and polish.

• Office Hours. These are a type of optional, opt-in work sessions that I host once a week for two hours. 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.

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.

9/18-10/2: Starting the New Project

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

Encounters System (6 hours)

A lot of my “in engine” time was spent on the encounters system. The encounters system is a general term for the system that enables designers to define the flow of the campaign. The creation of it consisting of the following elements:

• The creation of a system of inheritable scriptable objects that allows designers to create encounters inside the editor. This system supports narrative scenes, ship building scenes, and combat encounters

• A refactor of the game management system to allow ships to be spawned in at the start of scenes. Previously, the enemy ship existed in the scene at the start. Now, the game spawns the game. This ensures the number of scenes is limited, as there is only one combat Unity scene that is constantly being used.

• A campaign scriptable object that defines the order of each encounter. This allows them to be played in a linear sequence. In addition, designers can create and rework the order of elements as they wish.

Repository Management (3 hours)

I spent two hours this week on maintaining the repository, which involves merging pull request, fixing Merge Conflicts and hotfixing the build when needed. I merged in 48 pull requests these past two weeks, which is a higher amount than previous projects. A large part was spent giving feedback on pull requests. I don’t want to be strict on pull requests, as that severely limits productivity and morale. However, there were many instances when pull requests contained code that didn’t compile, didn’t contain necessary files, or didn’t implement the required tasks, and I had to write feedback on what needed to be improved.

There were only a few merge conflicts these past two weeks (which is a testament to how many people are being careful). However there were some merge conflicts that were hard to solve, either because they were large or ended in a substantial duplication of assets. In addition, there were some merges that created compilation errors and softlocks. For instance, the implementation of in-combat dialogue required the time scale to be set to 0, which broke narrative scenes, so I had to reverse those changes to prevent a softlocking bug.

Programming Meetings & Office Hours (6 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. In addition, this week I provided a problem-solving demonstration where I taught them how to use VS Code.

• 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.

Task Creation and JIRA (3 hours)

A large part of my week was JIRA management of the project. My job was to create a lot of these tasks (30+ JIRA tasks). I put sufficient detail into these tasks to ensure programmers had guidance and clear objectives. I’m continuing my long-running tradition of adding a “HELPFUL LINKS” section to each task (this idea was inspired by the Hints documents in EECS 494). A major problem in previous semesters was that members often struggled with figuring out how to implement their tasks, and often were directionless when facing new tasks. This problem is exacerbated by the number of new programmers and the fact that this is a really complex codebase. To combat this, I created this sections to guide programmers on where to find relevant information (this has the added bonus of familiarizing them with our resources).

4/3-4/17: The Final Iterations

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

Bug Fixes & Tweaks (8 hours)

Almost all my time this sprint was spent on bug fixes and tweaks. While it is not the most glamorous way to spend a sprint, it was important work. The bugs I fixed were:

• Removed the “configure screen” (the first screen at the start of the level) and allowed the player to be selected from the main menu.

• Replaced the concept art on the player select screen with the high fidelity character art

• Fixed a bug where if the stick is turned during a roll, it won’t be saved.

• Prevented the player from taking damage while respawning

• Allowed the input devices to reset in the main menu

• Recentered the basic enemy to prevent strange bugs with the way the enemy renders

• Fixed several null reference errors.

• Prevented combo finisher from occuring when the enemy is dead

• Added the difficulty mode to the game

• Prevented inputs from clearing on stun

• Integrated the final narrative scene to the game

• Fixed a bug where the player would not have iframes when they roll

• Fixed the “fetal position” bug

• Preventing player from rolling through the barrier

• Preventing the player from jumping outside of bounds

Leads Meetings (5 hours)

As Project Lead, one of my responsibilities is to create the agendas for leads meetings. These are meetings where we talk about our department’s progress, ensure we’re on the same page about important decisions, and discuss the next weeks of development. I spent roughly one hour a week typing up the agenda before the meeting. This allows us to create our quickly discuss all the points we feel are relevant. The leads meetings take roughly an hour per week. Overall, these meetings are really helpful for us to understand where we are and answer cross-departmental questions and dependencies.

Studio Meetings (5 hours)

As Project Lead, one of my responsibilities is to create half the slides for and host the studio meeting. I create slides on the project’s progress (including our burndown chart), what we’re doing in this sprint, and the MDP devlog process. The slides usually take an hour to create. Having these slides allows members to feel like the content of the meetings are structured. The meetings last for about two hours, as we now have members talk directly to designers after their department meetings. At each studio meeting, I usually hop into one of the department meetings (this week it was programming, last week it was art) and listen in, actively providing answers and insights.

3/20-4/3:

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

Bug Fixes & Tweaks (5 hours)

A lot of my time was spent fixing various bugs and adding various tweaks in the game. These include:

• Fixing the hitbox of the boss to allow it to damage the player.

• Adding “encounter bounds” to the boss to allow the camera to move with the player, rather than restrict the player to just moving right.

• Fixing a bug where the boss would not flip horizontally

• Allowed players to collide with the door at the club entrance

• Removed the ability to roll while in the air

• Reenabled the sideways jump kick

• Fixed the ability to preserve momentum while jumping

• Fixed a latent bug where the mouse will be disabled after enabling the developer console

• Added i-frames to the player’s roll

While each individual bug did not take much time to solve, a lot of the time was spent actually replicating the bug so it could be fixed. These bug fixes ended up improving the player experience significantly.

The Brandon Move (1 hour)

In addition to bug fixes and minor tweaks, I spent some time this week implementing a new move for the player’s mobility. Informally called the “Brandon Move” after its designer, Brandon Schultz, the move launches the player in the air if they double-tap the roll button twice. This allows the player to have greater mobility options and forces them to jump in the air and potentially use the kick.

I spent some time refactoring the player’s dash to accommodate this new move. One thing that surprised me was that the roll functionality was on the PlayerController script rather than the CharacterMotor script. While not a big deal, it is something I would refactor because the PlayerController was not meant to directly handle dashing.

Enemy II Adjustments (3 hours)

Last week, our programmers completed the functionality for the heavy enemy (enemy II). However, there was a miscommunication between art and design about what the enemy would do for an attack. Design originally wanted a really strong attack, such as a big punch, and made the state machine diagram with this in mind. However, the art department made the animations into a dash. When programming implemented the state machine diagram exactly with the dash in place of the attack, it led to really strange behavior.

To solve this problem, I contacted our enemy and combat designer, Brandon, to talk about how the dash changes the enemy’s behavior. He created a new state machine that accounted for all of this. The main difference was the enemy will move to somewhere near the player before initiating the dash. In addition, the enemy should blink before doing the dash to telegraph the attack. I spent a couple of hours making the necessary adjustments to the heavy enemy script. By the end, the heavy enemy was much better to play with.

Leads Meetings (4 hours)

As Project Lead, one of my responsibilities is to create the agendas for leads meetings. These are meetings where we talk about our department’s progress, ensure we’re on the same page about important decisions, and discuss the next weeks of development. I spent roughly one hour a week typing up the agenda before the meeting. This allows us to create our quickly discuss all the points we feel are relevant. The leads meetings take roughly an hour per week. Overall, these meetings are really helpful for us to understand where we are and answer cross-departmental questions and dependencies.

Studio Meetings (6 hours)

As Project Lead, one of my responsibilities is to create half the slides for and host the studio meeting. I create slides on the project’s progress (including our burndown chart), what we’re doing in this sprint, and the MDP devlog process. The slides usually take an hour to create. Having these slides allows members to feel like the content of the meetings are structured. The meetings last for about two hours, as we now have members talk directly to designers after their department meetings. At each studio meeting, I usually hop into one of the department meetings (this week it was programming, last week it was art) and listen in, actively providing answers and insights.

3/6-3/20: The Core Game

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

Playtest & Notes (4 hours)

Over the past two weeks, I attended playtesting sessions with Matt Rader(Serenity Forge), Amber Renton(Microsoft), and Austin Yarger(Arbor Interactive). We have increased the frequency of our playtests because the game is in a state where we can get a lot of feedback. I took notes for both playtesting sessions and wrote down as many points as I could (an example of which is shown above). They were able to pinpoint where the combat was working and where it wasn’t. In addition, I hosted my own playtesting session with Rachel Liu (Rice Games) to get more specific first impression feedback.

Fixing Enemies (5 hours)

During the playtest with Amber Renton (Microsoft), the enemies were experiencing incredibly strange bugs. They got stuck on geometry, rarely attacked the player, and overlapped with the player significantly. This was because the enemy programming was not managed effectively. The main problems with the enemies were:

• The enemies were initially architected with the intent to have reusable components for all the different states. However, these states were not well planned out and well communicated. I wasn’t able to pick up on this because I was busy focusing on other parts of the game.

• The enemies each had a “Brain” component that controls the overall logic. The brains were often 600+ lines and were monolithic classes. The logic and subclasses had too much spaghetti code to debug. As a result, when enemies broke, they were impossible to debug.

• The enemies went through 4 refactors in 5 weeks. The intent of various parts of the code was way too complicated to reason through.

As a result, I got together with Isaac Huffman to completely rewrite the enemy AI. We greatly simplified the architecture of the enemies into a simple, 200 line enemy controller. It had no modularity but was much simpler and easier to understand. I will address this with the programming department, but for now we need to move forward with the rest of the enemies.

Leads Meetings (4 hours)

As Project Lead, one of my responsibilities is to create the agendas for leads meetings. These are meetings where we talk about our department’s progress, ensure we’re on the same page about important decisions, and discuss the next weeks of development. I spent roughly one hour a week typing up the agenda before the meeting. This allows us to create our quickly discuss all the points we feel are relevant. The leads meetings take roughly an hour per week. Overall, these meetings are really helpful for us to understand where we are and answer cross-departmental questions and dependencies.

Studio Meetings (4 hours)

As Project Lead, one of my responsibilities is to create half the slides for and host the studio meeting. I create slides on the project’s progress (including our burndown chart), what we’re doing in this sprint, and the MDP devlog process. The slides usually take an hour to create. Having these slides allows members to feel like the content of the meetings are structured. The meetings last for about one hour. At each studio meeting, I usually hop into one of the department meetings (this week it was programming, last week it was art) and listen in, actively providing answers and insights.

Merging Pull Requests (2 hours)

I spent a significant amount of time this week merging pull requests and solving merge conflicts. This week, 73 pull requests were merged in, about 70% (about 50) were merged in by me. There were 4 merge conflicts, 3 of which were simple. However, much of my time (about 45 minutes) was spent on a merge conflict with our audio director, whose changes were so sweeping as to cause several merge conflicts. No merge strategy worked, so I had to add the audio director to redo his changes on a new branch.

Breakdown

Playtest & Notes (4 hours)

Fixing Enemies (5 hours)

Lead Meetings (4 hours)

Studio Meetings (4 hours)

Merging Pull Requests (2 hours)

Total (19 hours)

2/6-2/20: Going into Alpha

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

Task Creation (1.5 hours)

I spent time making tasks for the programming departments this sprint. These tasks came primarily from playtesting feedback, talks with the design department, and the features I know are unimplemented. Many programmers said my method of making tasks with a HELPFUL LINKS section and a NOTES section assisted them in their task (this is blatantly inspired by Austin Yarger’s teaching techniques, I’m sure he won’t mind). These tasks include bug fixes, new features pitched by design, new tools for designers, and improvements to existing systems.

Notes for Playtesting Sessions (1.5 hours)

Over the past two weeks, I attended playtesting sessions with Jordan Ajlouni and George Castle. They played the most recent builds of our game. Because those builds are incomplete, most of our time with our advisors was focused on our approach to design and art. I took notes for both playtesting sessions and wrote down as many points as I could (an example of which is shown above). They gave us valuable insight into where to go next and what to focus on. In addition, they found many bugs (which we can fix during production).

Cheat Code Experiments (1 hour)

I decided to create some cheat codes so our development team can experiment with changing different values at runtime. This can be particularly useful when we want to test out values in the build themselves, rather than in the editor. One of the cheat codes I created was SetComboTime. Calling setcombotime in the console with a float argument sets the combo time (the amount of time between combo hits) to the argument. Making a new cheat command was pretty easy; because of our existing reflection system, commands are automatically integrated when you make the class. This allowed me to confirm that combos were actually working in the build (which was unclear). In the future, I plan to experiment with more cheats code to help our development team.

Pause Menu Integration (1 hour)

This week, our programmers created a good pause menu. However, it only existed in a lab scene and was not integrated into the main game. I took the initiative to add this menu to all the scenes. I reworked the existing UI architecture into a “UI Package” prefab. This package includes the HUD canvas, the pause menu canvas, and the developer’s console. Now, whenever a developer wants to create a new scene, they can just import the ‘UI Package’ prefab and the scene just works.

Cooperative Multiplayer Bug Fixes (4 hours)

Previously the cooperative multiplayer system does not work as intended. Whenever a player connects a keyboard and a gamepad, both players respond to gamepad inputs, while only one responds to keyboard inputs. We want one player to respond to keyboard inputs and another player to respond to gamepad inputs. This was a really hard bug to solve, because we were dealing with Unity’s player handling code, not ours.

After a lot of debugging, I traced it back to a single line in our code. A few weeks ago, when first implementing cooperative multiplayer, there was a bug where the PlayerInput class spawned a lot players into an empty scene. As a result, we decided to handle player spawning manually. This created issues where we weren’t using the PlayerInput API correctly. I traced our issues to a line in our code where we assign each player a controls object. However, this is something the PlayerInput API is supposed to handle, so us handling it caused the player’s controls object to be in a damaged state.

Leads Meetings (4 hours)

As Project Lead, one of my responsibilities is to create the agendas for leads meetings. These are meetings where we talk about our department’s progress, ensure we’re on the same page about important decisions, and discuss the next weeks of development. I spent roughly one hour a week typing up the agenda before the meeting. This allows us to create our quickly discuss all the points we feel are relevant. The leads meetings takes roughly an hour per week. Overall, these meetings are really helpful for us to understand where we are and answer cross-departmental questions and dependencies.

Studio Meetings (5 hours)

As Project Lead, one of my responsibilities is to create half the slides for and host the studio meeting. I create slides on the project’s progress (including our burndown chart), what we’re doing in this sprint, and the MDP devlog process. The slides usually take an hour to 1.5 hours to create. Having these slides allows members to feel like the content of the meetings are structured. The meetings last for about one hour. At each studio meeting, I usually hop into one of the department meetings (this week it was programming, last week it was art) and listen in, actively providing answers and insights.

11/28-12/12: Bug Fixes and Next Semester

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

Tooltip System (1 hour)

After receiving playtesting data, the team realized that people were confused about what tower upgrades did because there were no descriptions. The UI layout didn’t have any space to put this information, so we decided to communicate them through a tooltip. According to the first result on google, a tooltip is a brief, informative message that appears when a user interacts with an element in a graphical user interface. When mousing over tower upgrades, a tooltip with the name and description of the tooltip. This is technology I ported over from Caduceus, so the task was really quick. From there, it was simply about making the tower upgrades set the tooltip when they are hovered over.

Bug Fixes (1 hour)

I spent some time investigating and fixing a very strange bug with the support tower. Basically, the tower placement mechanics work by doing a circle cast at the mouse position with a certain radius specified by the tower. If the cast returns false, the tower can be placed there. The issue is that the cast places the tower at the center of the prefab, not the center of the sprite (you can see a visualization above). This essentially means that the support tower can be placed on top of the path (or at the very least appear to be placed on top of the path). I made the circle cast be at an offset to the spawn point, making the tower placement more accurate to the visuals. This took a long time to actually figure out, but solving it wasn’t too complicated.

Design Changes (2 hours)

I made a few design changes in response to feedback from designers:

• Split the third level enemies between the different paths. Levels work by using something called an level config, which specifies which enemies go on which rounds. During preproduction, my team and I created a couple tools to help us deal with level configs. The first is a Level Config Builder, which allows you to build level configs from other level configs and from configurable presets (see below). The second is a Level Config Editor, which allows you a better interface to understand how the level operates and flows.

• Added functionality for in-game dialogue before the first round. When the game started, a character would be able to tell something to the player. This wasn’t a difficult change, simply a few lines of code and some extra variables to enable this.

• Added a win screen in the final cutscene. This did involve a bit of a refactor to make the visual novel system a bit more generic (i.e. have a unity event on the end, don’t just skip to the next scene), but it wasn’t too difficult.

Project Management (2 hours)

A lot of my time was spent on managing the programmers and the project. These responsibilities include:

• Make JIRA tasks for programmers and designers based on playtesting feedback. These were really simple because all we had were tweaks and bug fixes. Because the programmers were much more familiar with the codebase, I didn’t feel it was important to make a HELPFUL LINKS section.

• Reviewing and merging pull requests. There were 27 pull requests and zero merge conflicts (surprisingly), although we did have a dangling meta file (which was very odd).

Postmortem and Reflection (1 hour)

For as long as I’ve been a part of the WolverineSoft Studio, I’ve struggled a lot with how to be a good leader. So I felt it was important to take a chunk of time to talk to all my programmers and designers and get some feedback. Here is some of the positives:

• Overall, the semester went very well. There were no scope cuts and the vast majority of things got done on or ahead of schedule (only a single programming task was behind schedule). Because we weren’t being delayed, the team had a lot of morale and this led to even more productivity.

• I think I architected code pretty well. Each class is pretty small and the responsibilities are divided between them somewhat well. This led to pretty minimal spaghetti, allowing the team to have increased productivity.

• Programmers didn’t waste much time trying to navigate the codebase, in part because the codebase isn’t that big and in part because all the JIRA tasks at the beginning have a HELPFUL LINKS and a POSSIBLE IMPLEMENTATION section (where applicable). Austin Yarger’s project management techniques worked very well, and I hope to ask him for more in the future.

• People generally say they were well supported by me. I’ve struggled with giving too much guidance (which can be very handholdy) vs. not giving enough guidance (which leads to people feeling lost). I think giving my teammates a set of helpful links and some ideas on how to get started while letting them venture outside my ideas if they wanted to stroke a good balance.

However, there are a few things that could be improved (pretty minor though):

• I made sure to make lots of documentation, but the major thing that slipped through is documenting how and why systems are architected. For instance, the data about the tower isn’t on the scriptable object, it’s stored in components on the prefab. This is because every tower needs different things (for instance, most towers need to shoot at a target, but the Support tower doesn’t), so towers are composed of components. However, this lead to confusion with other people, who expected it to be on the scriptable object. I think documenting how and why these decisions are made would really help.

• Ensuring clear project goals from the start of preproduction, not the start of production. I spent the prototyping stage thinking I was developing a case study of Bloons TD 5, not Bloons TD 6 (which was what we eventually changed it to). This meant that things like the tower upgrades menu was implemented with poor code quality. Making these expectations clear from the start would have helped a lot.

• I could have done important stuff a bit earlier rather than waiting for a while. For instance, I should have implemented WWise before production, and not during so audio wouldn’t waste its time with complicated technical problems.

Next Semester Planning (4 hours)

I spent a lot of time this week planning for the Winter 2022 semester studio. We' decided to start planning well in advance of the next semester in order to give ourselves more time to prepare. This is a strategy that proved itself well this semester. I spent these two weeks attempting to narrow down the case studies from 5 to 1. The main thing I wanted to figure out for each game was “what does the development of this game look like?” Doing these thought exercises would help me better anticipate potential problems and give me a more clear picture of each game. The main things I did were:

• Try to experience the game in some way. I already had one (The Binding of Isaac) and I was able to go to the CVGA to experience one (Teenage Mutant Ninja Turtles). For the other three, I had to carefully watch walkthroughs of each game (I can’t believe the CVGA doesn’t have Hyper Light Drifter).

• Look at the WolverineSoft General Library and see what each game would start with. All games could use the basics of the library but there were some that could use special scripts (like Inventory for Binding of Isaac and Parallax for Starfy).

• Come up with a task list for each game. Here is an example of one for Teenage Mutant Ninja Turtles:

In the end, we chose our case study for next semester: CONFIDENTIAL

Final Build (1 hour)

I did a check of the build for the final submission to our itch.io page. I played through and beat the game, thus making sure there were no issues (there were a few balancing I would have wanted, however, but that’s inconsequential). I then made the final build for Windows and submitted it to Amber Renton for the itch page. This marked the end of development, and I couldn’t be prouder of the team and the overall final product.

11/14-11/28: Additional Polish and Next Semester

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

Art Integration (1 hour)

I spent some time integrating the tower upgrade art into the game. I added the upgrade art for five towers (Axe, Magic, Spear, Support, and Explosive), so the sprites change when the tower is upgraded (an example is shown above). This wasn’t too hard of a task; the main challenge was coordinating getting the sprites and converting between different file formats. This made a difference to the final product, allowing players to easily identify which towers were upgraded and which weren’t.

Bug Fixes (2 hours)

I spent a bunch of time fixing various bugs in the game. Here is a list of what I worked on:

• Fixed a bug where gold text act strange if the gold was more than 10,000 (for instance, 10000 gold would read as 10,00). Surprisingly, this wasn’t a bug in the code; rather the gold text would overflow the text container, leading to a very strange display. Fixing this involved expanding the box.

• Fixed a bug where the explosive damage event would go off multiple times in a single second. The explosive damage script damages multiple enemies, and the event was invoked inside the for-loop. Fixing this bug involved tracking down the loop and moving the line of code.

• Fixed a bug where the tower can be dropped on a bunch of different buttons. Fixing his involved added a non-droppable rect onto the various buttons.

• Fixed a bug where the back button on the difficulty select screen takes you back to the level select screen, not the mode select screen on the campaign mode. Fixing this involved adding a branch in the code that controls the main menu.

• Fixed a bug where the tower screen enable button would not face in the correct direction. Fixing this involved creating a custom script to flip the button when it is pressed.

Balancing Changes (1 hour)

I made a bunch of balancing changes in response to feedback from the WolverineSoft Playtesting List. They are:

• Making the Axe tower slightly less powerful (50% decrease in fire rate)

• Making the Archer tower slightly more powerful (22% increase in fire rate)

• Added the lead ghosts in an earlier round to ease players into the game.

• Rebalanced Round 38 by increasing the time between enemies, increasing the time between waves, and reducing the number of enemies

Next Semester Planning (4 hours)

I spent a lot of time this week planning for the Winter 2022 semester studio. We' decided to start planning well in advance of the next semester in order to give ourselves more time to prepare. This is a strategy that proved itself well this semester. Because the prototype was finished well in advance of the kickoff, I was able to spend preproduction (which we define as the time between the application decisions and the studio kickoff) making experimental tools, onboarding new programmers, and creating documentation. If I had to spend that time making the prototype, my time would have been split and I would have been less productive. We’re going to replicate this strategy for the next semester.

I spent a bunch of time in meetings this week trying to plan out the details of the next iteration of the studio. Here are the things we determined:

• We will be doing one project in Unity of about 25 people.

• We will be doing a case study of some kind

• We will bring back designers (we decided not to this semester because we believed we couldn’t give them tasks, but our lack of designers has proven to really hurt us).

• We have a concrete schedule for next semester’s production

• We have a list of 5 case studies to choose from for the next semester. We will be meeting with some people over the next two weeks to discuss which one we should pursue (including our friends at Arbor Iteractive)

Project Management (4 hours)

lot of my time was spent on managing the programmers and the project. These responsibilities include:

• Make JIRA tasks for programmers and designers based on playtesting feedback. Many programmers said my method of making tasks with a HELPFUL LINKS section and a POSSIBLE IMPLEMENTATION section assisted them in their task (this is blatantly inspired by Austin Yarger’s teaching techniques, I’m sure he won’t mind). Upon further questioning, students said this helped reduce the time they spent lost in the codebase. I created their tasks with these sections (at least where applicable).

• Reviewing and merging pull requests. There was only one merge conflict and 20 pull requests, which wasn’t too hard to merge in.

• Checking in with members and assisting them with implementation. This mainly involves answering their questions about how the code works and directing them to the relevant parts of the codebase. Overall, it seems that students find the codebase easy to navigate, especially with the HELPFUL LINKS section of the JIRA tasks (it also helps that the codebase isn’t that big, I’d estimate around 5k lines of original code)